graphicsfandomcom-20200214-history
PNG
PNG (Portable Network Graphics) is a losslessly compressed bitmap image format. PNG was created to both improve upon and replace the GIF format with an image file format that does not require a patent license to use. PNG is officially pronounced as "ping" ( in IPA), but it is often just spelled out — possibly to avoid confusion with the network tool ping. PNG is supported by the libpng reference library, a platform-independent library that contains C functions for handling PNG images. PNG files nearly always use the file extension PNG or png and are assigned the MIME media type image/png (approved on October 14 1996). History and development The motivation for creating the PNG format came in early 1995, after Unisys announced that it would be enforcing software patents on the LZW data compression algorithm used in the GIF format (the acronym PNG was originally recursive, standing for "PNG's Not GIF"). For more on this controversy see GIF (Unisys and LZW patent enforcement). There were also other problems with the GIF format which made a replacement desirable, notably its limitation to 256 colors at a time when computers capable of displaying far more than 256 colors were becoming common. Although GIF allows for animation, it was decided that PNG should be a single-image format. A companion format called MNG has been defined for animation. PNG gained some additional popularity in August 1999, after Unisys terminated its royalty-free patent licenses to developers of free software and non-commercial software. *Version 1.0 of the PNG specification was released on July 1 1996, and later appeared as RFC 2083. It became a W3C Recommendation on October 1 1996. *Version 1.1, with some small changes and the addition of three new chunks, was released on December 31 1998. *Version 1.2, adding one extra chunk, was released on August 11 1999. *PNG is now an International Standard (ISO/IEC 15948:2003), also released as a W3C Recommendation on November 10 2003. This version of PNG differs only slightly from version 1.2 and adds no new chunks. Technical details File header A PNG file starts with an 8-byte signature. The hexadecimal byte values are 89 50 4E 47 0D 0A 1A 0A. Each of the header bytes is there for a specific reason http://www.libpng.org/pub/png/spec/1.1/PNG-Rationale.html#R.PNG-file-signature: "Chunks" within the file After the header come a series of chunks each of which conveys certain information about the image. Chunks declare themselves as critical or ancillary, and a program encountering an ancillary chunk that it does not understand can safely ignore it. This chunk-based structure is designed to allow the PNG format to be extended while maintaining compatibility with older versions. The chunks each have a header specifying their size and type. This is immediately followed by the actual data, and then the CRC of the data. Chunks are given a 4 letter case sensitive name. The case of the different letters in the name provides the decoder with some information on the nature of chunks it does not recognise. The case of the first letter indicates if the Chunk is essential or not. If the first letter is uppercase, the chunk is essential. If not, the chunk is ancillary. Essential chunks contain information that is necessary to read the file. If a decoder encounters an essential chunk it does not recognise, it must abort reading the file. The case of the second letter indicates if the chunk is "public" (either in the specification or the registry of special purpose public chunks) or "private" (not standardised). Uppercase is public and lowercase is private. This ensures that public and private chunk names can never conflict with each other. The third letter must be uppercase to conform to the PNG specification. It is reserved for future expansion. The case of the fourth letter indicates if a chunk is safe to copy by editors that do not recognise it. If lowercase the chunk may be safely copied regardless of the extent of modifications to the file. If uppercase it may only be copied if the modifications have not touched any critical chunks. Essential chunks A decoder must be able to interpret these to read and render a PNG file. * IHDR must be the first chunk, it contains the header. * PLTE contains the palette; list of colors. * IDAT contains the image, which may be split among multiple IDAT chunks. Doing so increases filesize slightly, but makes it possible to generate a PNG in a streaming manner. * IEND marks the image end. Metadata chunks Other image attributes that can be stored in PNG files include gamma values, background color, and textual metadata information. PNG also supports color correction with the use of color management systems like sRGB. * bKGD gives the default background color. * cHRM gives the white balance. * gAMA specifies gamma. * hIST can store the histogram, or total amount of each color in the image. * iCCP is an ICC color profile. * iTXt contains international (UTF-8) text, compressed or not. * pHYs is the physical size of the image. * sBIT (significant bits) indicates the color-accuracy of the source data. * sPLT suggests a palette to use if the full range of colors is unavailable. * sRGB indicates that standard RGB colors are used. * tEXt can store text that can be represented in ISO 8859-1, with one name=value pair for each chunk. * tIME stores the time that the image was last changed. * tRNS contains transparency information. For indexed images, it stores an alpha channel value for each palette entry. For truecolor and greyscale images, it stores a single pixel value that is to be regarded as transparent. * zTXt contains compressed text with the same limits as tEXt. The lowercase first letter in these chunks indicates that they are not needed for the PNG specification. The lowercase last letter in some chunks indicates that they are safe to copy, even if the application concerned does not understand them. Color depth PNG images can either use palette-indexed color or be made up of one or more channels (numerical values directly representing quantities about the pixels). When there is more than one channel in an image all channels have the same number of bits allocated per pixel (known as the bitdepth of the channel). Although the PNG specification always talks about the bitdepth of channels, most software and users generally talk about the total number of bits per pixel (sometimes also referred to as bitdepth or color depth). The number of channels will depend on whether the image is greyscale or color and whether it has an alpha channel. PNG allows the following combinations of channels: The full range of color options bitdepth per channel 1 2 4 8 16 indexed (color type 3) 1 2 4 8 greyscale (color type 0) 1 2 4 8 16 greyscale & alpha (color type 4) 16 32 truecolor (RGB - color type 2) 24 48 truecolor & alpha (RGBA - color type 6) 32 64 * greyscale * greyscale and alpha (level of transparency for each pixel) * red, green and blue (rgb/truecolor) * red, green, blue and alpha With indexed color images, the palette is always stored at a depth of 8 bits per channel. The palette must not have more entries than the image bitdepth allows for but it may have fewer (so if an image for example only uses 90 colors there is no need to have palette entries for all 256). Indexed color pngs are allowed to have 1, 2, 4 or 8 bits per pixel by the standard; greyscale images with no alpha channel allow for 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bitdepth per channel of either 8 or 16. The combinations this allows are given in the table on the right. The green cells with numbers represent the supported formats, the numbers inside the total bits per pixel. The red cells represent unsupported combinations. The standard requires that decoders can read all supported color formats but many image editors can only produce a small subset of them. Transparency of image PNG offers a variety of transparency options. With truecolor and greyscale images either a single pixel value can be declared as transparent or an alpha channel can be added. For paletted images, alpha values can be added to palette entries. The number of such values stored may be less than the total number of palette entries, in which case the remaining entries are considered fully opaque. The scanning of pixel values for binary transparency is supposed to be performed before any color reduction to avoid pixels becoming unintentionally transparent. This is most likely to pose an issue for systems that can decode 16 bits per channel images (as they must to be compliant with the specification) but only output at 8 bits per channel (the norm for all but the highest end systems). Compression PNG uses a non-patented lossless data compression method known as deflation. This method is combined with prediction, where for each image line, a filter method is chosen that predicts the color of each pixel based on the colors of previous pixels and subtracts the predicted color of the pixel from the actual color. An image line filtered in this way is often more compressible than the raw image line would be, especially if it is similar to the line above (since deflate has no understanding that an image is a 2D entity, and instead just sees the image data as a stream of bytes). Interlacing PNG offers an optional 2-dimensional, 7-pass interlacing scheme – the Adam7 algorithm. This is more sophisticated than GIF's 1-dimensional, 4-pass scheme, and allows a clearer low-resolution image to be visible earlier in the transfer. Animation PNG does not offer animation. MNG is an image format that supports animation and is based on the ideas and some of the chunks of PNG but is a complex system and does not offer fallback to single image display like GIF does. APNG is another image format based on PNG that supports animation and is simpler than MNG. APNG offers fallback to single image display for PNG decoders that do not support APNG. However neither of these formats are widely supported. Technical comparison with GIF * On most images, PNG can achieve greater compression than GIF (but see the section on filesize, below). * PNG gives a much wider range of transparency options than GIF, including alpha-channel transparency. * PNG gives a much wider range of color depths than GIF (truecolor up to 48-bit compared to 256-color), allowing for greater color precision, smoother fades, etc. http://www.libpng.org/pub/png/pngintro.html * GIF supports animation while PNG does not (but see the section on animation, above). * PNG images are not as widely supported as GIF images. Bitmap graphics editor support for PNG Macromedia Fireworks uses PNG as its native file format but by default also stores metadata for layers, animation, text and effects. Such files should not be distributed directly. Fireworks can instead export as an optimised PNG without the extra metadata for use on webpages etc.http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_13871 Other popular graphics programs which support the PNG format include Adobe Photoshop, The GIMP and GraphicConverter. Programs that support PNG and are bundled with popular operating systems include Microsoft's Paint and Apple's iPhoto. Some image processing programs have PNG compression problems, mainly related to lack of full implementation of the PNG compressor library: *IrfanView 3.85 (IrfanView 3.98 has been updated to use the PNGout plugin by Ken Silverman) *Microsoft Picture It! Photo Premium 9. *Macromedia Fireworks Web browser support for PNG Despite campaigns such as "burn all gifs" http://burnallgifs.org/, tools such as gif2png http://www.catb.org/~esr/gif2png/, calls by the Free Software Foundation, and influential writers, PNG adoption on websites has been fairly slow. GIF is still more widely used than PNG, partially due to misconceptions but also for several real reasons: *On very old browsers such as Internet Explorer 3, PNG support may not be available *GIF images support animation, which is often used in Internet advertising. The full feature set of PNG is not often used on the web, for several reasons *Internet Explorer 4 can crash on images containing metadata (e.g. Macromedia Fireworks's native PNG file format) *Versions of Internet Explorer up to 6 do not support native alpha-channel transparency. Although still in beta, IE7 supports PNG transparency. The fact that Internet Explorer does not support alpha-channel transparency has led some people to erroneously believe that Internet Explorer does not support transparency at all. However PNGs can be given a single transparent background color, which works on IE, and is equivalent to the transparency available with GIF images. There are also a number of methods using DirectX functions in style sheets and HTML that can make Internet Explorer display full transparency data in PNG images on web pages. Filesize and Optimisation Software Generally, PNG files created by a decent encoder and without unwanted metadata should be smaller than the identical image encoded in GIF format. However, PNG gives the image creator far more flexibility than GIF and care needs to be taken to avoid PNG files that are needlessly large. As GIF is limited to 256 colors, many image editors will automatically reduce the color depth when saving an image in GIF format. Therefore when people save the same truecolor image as PNG and GIF they see that the GIF is smaller (they may also see that the PNG is higher quality depending on the original image and the quality of the color reduction). They do not realise it is possible to create a 256 color PNG that has identical quality to the GIF but has a smaller filesize than the GIF, and so they develop the misconception that PNG files are larger than "equivalent" GIF files. Some versions of Adobe Photoshop and CorelDraw have been reported to have poor PNG output support, further fuelling the idea that PNG is larger than GIF. Many graphics programs (even Apple's Preview software) save PNGs with large amounts of metadata and also color-correction data that's generally unneccesary. Unoptimized PNG files from Macromedia Fireworks are also notorious for this. Various tools are available for optimizing PNG files. OptiPNG and pngcrush are both Open-source software optimizers for PNG files that can be run from a command line in a Windows Command Prompt or from a Unix or Linux command line, and are very effective at reducing the size of PNG files for the web, especially those exported from the graphics creation programs with poor PNG handling. Other tools such as AdvanceCOMP and Ken Silverman's PNGOUT are capable of reducing the filesize even further, practically giving the competent user the smallest filesize possible for a given PNG image. pngcrush has the extra ability to remove all color correction data from PNG files (gamma, white balance, ICC color profile, standard RGB color profile). This can often result in significantly smaller file sizes, and it's achieved with the following command line options: pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB InputFile.png OutputFile.png PNG was not intended to replace the other popular web image format JPEG. See the Comparison with JPEG section below for more details on how the two formats compare. Comparison with JPEG JPEG will produce a smaller file than PNG for photographic (and photo-like) images since it uses a lossy encoding method specifically designed for photographic image data. Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize (often 5-10 times) with negligible gain in quality. PNG is a better choice than JPEG for storing images that contain text, line art, or other images with sharp transitions that do not transform well into the frequency domain. Where an image contains both sharp transitions and photographic parts a choice must be made between the large but sharp PNG and a small JPEG with artifacts around sharp transitions. JPEG is a poor choice for storing images that may need to be edited further as it suffers from generation loss issues, whereas PNG is a lossless file format and is therefore better suited to storage and recovery of images that are likely to be further edited. Comparison with TIFF TIFF is a complicated format that incorporates an extremely wide range of options. While this makes it useful as a generic format for interchange between professional image editing applications, it makes supporting it in more general applications such as Web browsers difficult. It also means that many applications can only read a subset of TIFF types creating a compatibility problem. The most common general-purpose lossless compression algorithm used with TIFF is LZW, which is inferior to PNG and suffers from the same patent issues that GIF does. There is an option to use the same compression algorithm with TIFF as PNG uses, but it is not supported by many proprietary programs. TIFF also offers special-purpose lossless compression algorithms like CCITT Group IV, which can compress black and white text better than PNG's compression algorithm. See also *Digital image editing *Computer Graphics, including: **Comparison of layout engines (graphics) *Related graphics file formats **APNG **JNG **MNG *Image file formats External links libpng.org *PNG Home Site *libpng Home Page *PNG-supporting browsers - overview of PNG status in different web browsers. First Windows IE support in 4.0b1; Netscape 4.04 http://oregon.usgs.gov/png_images.html. *[http://www.libpng.org/pub/png/slashpng-1999.html The Story of PNG by Greg Roelofs] *[http://www.libpng.org/pub/png/book/ PNG: The Definitive Guide (Online Version) by Greg Roelofs] W3C *PNG Specification (Second Edition), W3C Recommendation [[10 November] 2003] *Test inline PNG images Others *RFC 2083 *PNG transparency test *“The Lonely Planet” - A PNG-based animation for web browsers *Transparent PNG Generator *The GD-library to generate dynamic PNG-files with PHP *A guide to PNG optimization *PNG as a future proof format *PNG Adam7 interlacing *List of PNG-related resources, libraries and papers Internet Explorer incompatibility *PNG Files Do Not Show Transparency in Internet Explorer *The PNG problem in Windows Internet Explorer *png transparency in IE Category:Graphics file formats Category:Graphics standards Category:ISO standards Category:W3C standards